Generally, quality metrics will be used for reporting in 3GPP Packet-switched Streaming Services (PSS), where a service provider (server) needs information about the received quality of a video stream delivered to a client (see e.g. 3GPP TS26.234 V 5.3.0 Release 5). To be able to collect this information at the server, the client has to send feedback information about the received quality to the server. This information can only be created at the client, since conditions on the intermediate network and the client itself might influence the received quality of a video stream. The reported metrics are objective (e.g. amount of lost packets during the streaming session) since information about the quality of the delivery should be measured and not about the quality of the content (e.g., bad quality due to bad encoding of the video.) Since all the metrics are objective and not subjective, they can be automatically created at the client without any user interaction.
Packet-switched Streaming Services in 3GPP networks are based on the mechanisms that were invented for streaming in the wired Internet. Hence, known transport protocols, such as RTP/RTCP are used for the data transport (the actual streaming), while RTSP is used to control the streaming session. It has been shown that standardized mechanisms are not sufficient to report quality metrics about the perceived quality at the receiver. E.g., the information that is transported by RTCP receiver reports allows the sender to draw only rudimentary metrics about the quality of the delivered stream, like the number of group members, an RTT estimation to the receivers and the cumulative number of packets lost. These are not enough to inform the server about the quality of the streaming to each receiver. For example the cumulative number of packets lost does not provide precise information about the RTT on which it happened or which packets were actually received and lost. This fact hampers a proper adaptation by the server (rate and quality) and also the application of billing schemes, which will gain in importance as the streaming services become more popular. Therefore an extended mechanism is needed. Summarizing, there are two major problems with the RTCP-based quality metrics reporting:
The transport protocol (usually UDP) used for RTCP messages is not reliable and, thus, the quality metrics cannot be determined reliably.
The information contained in the RTCP receiver report is very restricted and does not give the operators much freedom to specify their own quality metrics.
A detailed overview about 3GPP PSS and the used protocols is given in 3GPP TS26.234 V 5.3.0 Release 5. RTCP is the control protocol for RTP, which is used to distribute control information about the RTP-based data transport. Two important message types in RTCP are sender and receiver reports that are used to exchange information about the data that is transported via RTP (e.g., the total amount of packets sent by the sender). In case the RTP session is based on UDP, which is the case for streaming, the RTCP data will also be transmitted via UDP. Since UDP is an unreliable protocol, a lossless transport of the RTCP data cannot be guaranteed. In order to avoid that RTCP message consume too much bandwidth, RTCP sender and receiver reports can only be sent in certain intervals (e.g., one receiver report each 5 seconds). Hence, the information that can be transmitted via sender and receiver reports is very limited and might not be sufficient to generate useful quality metrics timely. In particular, RTCP provides as exemplary basic metrics, an RTT estimation from sender to each receiver, delay jitter, cumulative number of packets lost, the highest sequence number received, and a packet count on how many packets the sender sent.
As mentioned in the previous section, these metrics are very limited and not extendable, so that new and existing applications (like MPEG4 video and AMR audio) lack a set of metrics to properly report on the received quality for each receiver.
RTSP is the signalling protocol that is used in PSS to control and set up a streaming session. It allows the client to start, stop the stream or jump to any position in time of the stream. Usually, RTSP data is transmitted reliably via the TCP protocol. Next to the control information additional information about the data transport characteristics is exchanged between server and client via RTSP. In addition, certain information can be exchanged during the streaming session.
Quality metrics define a certain set of parameters that are reported from the client to the server and allow the operator to draw conclusions about the quality a stream was delivered to the client. The usage of the information gained by those quality metrics can be manifold. E.g., a billing model could be based on such information or the operator could simply collect the data for its own statistics. As of today, the exact set of parameters for every kind of application is not known and it is debatable if one specific set will fit the needs of all operators in the future. There certainly is a limited set of quality metrics that is necessary in every case like the total amount of lost packets, a rough estimation of the RTT to the clients and an estimation of the delay jitter, as provided by RTCP. However, there are many application specific parameters while other parameters might only be of interest if content is streamed that has been encoded in a specific format.
Since it is not absolutely clear in which way the quality metrics will be used by the operator it would be desirable to find a solution that allows operators to define their own quality metrics for any kind of application. However, this is out of the scope of this invention. We assume the quality metrics subject of transport, which kind of transport is needed for each of the parameters and which peer is responsible for each of them is known to server and client.
To summarize, existing methods allow only limited possibilities of reporting quality metrics from the client to the server in a PSS. This is not sufficient for an operator to obtain a detailed and correct report about the received quality of a video stream at the client.